Changes

Fix getDatabricksClientForUnifiedProvider not copying commandFactory

Summary

• getDatabricksClientForUnifiedProvider creates a new DatabricksClient when routing to a specific workspace, but only copies the inner
  *client.DatabricksClient — it does not copy commandFactory, causing a nil pointer panic when resources call CommandExecutor()
• This affects databricks_mount, which executes Python on clusters via the Commands API and is the only resource using CommandExecutor through DatabricksClientForUnifiedProvider
• The fix copies commandFactory from the parent client, consistent with the existing pattern in ClientForHost (common/client.go:604)

Root Cause

getDatabricksClientForUnifiedProvider constructs the returned client as:

return &DatabricksClient{
DatabricksClient: client,
// commandFactory is missing!
}, nil

CommandExecutor() calls c.commandFactory(ctx, c), which panics when commandFactory is nil.

This bug was latent on main because resources using DatabricksClientForUnifiedProvider with a workspace-level provider always got workspaceID == "" from
state, short-circuiting to return the original client (which has commandFactory). The bug is only triggered when provider_config { workspace_id } is
explicitly set, routing through getDatabricksClientForUnifiedProvider.

Test plan

• Unit test: TestGetDatabricksClientForUnifiedProvider_CopiesCommandFactory — verifies CommandExecutor works on the returned client (both direct and via public API)
• Acceptance test: TestAccCreateDatabricksMountWithProviderConfig — creates a mount with provider_config { workspace_id } on a workspace-level provider, exercising the full code path end-to-end
• Verified without fix: cannot create mount: panic: runtime error: invalid memory address or nil pointer dereference
• Verified with fix: test passes
• All existing common/ unit tests pass

NO_CHANGELOG=true